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Abstract 


This document describes an Ethernet-Tree (E-Tree) solution framework 
for supporting the Metro Ethernet Forum (MEF) E-Tree service over a 
Multiprotocol Label Switching (MPLS) network. The objective is to 
provide a simple and effective approach to emulate E-Tree services in 
addition to Ethernet LAN (E-LAN) services on an existing MPLS 
network. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7387. 
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Introduction 


This document describes an Ethernet-Tree (E-Tree) solution framework 
for supporting the Metro Ethernet Forum (MEF) E-Tree service over a 
Multiprotocol Label Switching (MPLS) network. The objective is to 
provide a simple and effective approach to emulate E-Tree services in 
addition to Ethernet LAN (E-LAN) services on an existing MPLS 
network. 


This document extends the existing IETF-specified Layer 2 Virtual 
Private Network (L2VPN) framework [RFC4664] to provide the emulation 


of E-Tree services over an MPLS network. It specifies the E-Tree 
architecture reference model and describes the corresponding 
functional components. It also points out the gaps and required 


extension areas in existing L2VPN solutions such as Virtual Private 
LAN Service (VPLS) [RFC4761] [RFC4762] and Ethernet Virtual Private 
Network (EVPN) [EVPN] for supporting E-Tree services. 


1. Terminology 


This document adopts all the terminologies defined in RFC 4664 
[RFC4664], RFC 4761 [RFC4761], and RFC 4762 [RFC4762]. It also uses 
the following terms: 


Leaf Attachment Circuit (AC): An AC with Leaf role. An ingress 
Ethernet frame at a Leaf AC (Ethernet frame arriving over an AC at 
the Provider Edge (PE) of an MPLS network) can only be delivered 
to one or more Root ACS in an E-Tree service instance. An ingress 
Ethernet frame at a Leaf AC must not be delivered to any Leaf ACs 
in the E-Tree service instance. 


Root AC: An AC with Root role. An ingress Ethernet frame at a Root 
AC can be delivered to one or more of the other ACs in the 
associated E-Tree service instance. 

E-Tree: An Ethernet VPN service in which each AC is assigned the role 
of a Root or Leaf. The forwarding rules in an E-Tree are as 
follows: 


o The Root AC can communicate with other Root ACs and Leaf ACs. 


o Leaf ACs can only communicate with Root ACs. 
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2. Overview 


2.1. Ethernet Bridge Network 


In this document, "Ethernet bridge network" refers to the Ethernet 
bridge/switch network defined in IEEE 802.10 [IEEE802.10]. In a 
bridge network, a data frame is an Ethernet frame; data forwarding is 
based on destination Media Access Control (MAC) address; MAC 
reachability is learned in the data plane based on the source MAC 
address and the port (or tagged port) on which the frame arrives; and 
the MAC aging mechanism is used to remove inactive MAC addresses from 
the MAC forwarding table on an Ethernet switch. 


Data frames arriving at a switch may be destined to known unicast, 
unknown unicast, multicast, or broadcast MAC destinations. Unknown 
unicast, multicast, and broadcast frames are forwarded in a similar 
way, i.e., to every port except the ingress port on which the frame 
arrives.  Multicast forwarding can be further constrained when using 
multicast control protocol snooping or using multicast MAC 
registration protocols [IEEE802.10]. 


An Ethernet host receiving an Ethernet frame checks the destination 
address in the frame to decide whether it is the intended 


destination. 


2.2. MEF Multipoint Ethernet Services: E-LAN and E-Tree 


MEF 6.1 [MEF6.1] defines two multipoint Ethernet Service types: 


o E-LAN (Ethernet LAN), a multipoint-to-multipoint service 
o E-Tree (Ethernet Tree), a rooted-multipoint service 


The MEF defines User-Network Interface (UNI) in a multipoint service 
as the Ethernet interface between Customer Equipment (CE) and a 
Provider Edge (PE), i.e., the PE can send and receive Ethernet frames 
to/from the CE. The MEF also defines UNI roles in a multipoint 
Service. One role is Root, and another is Leaf. 


Note that MEF UNI in a service is equivalent to the Attachment 


Circuit (AC) defined in L2VPN [RFC4664]. The Root AC and Leaf AC 
defined in this document are the same as the Root UNI and Leaf UNI as 
defined in MEF 10.3 [MEF10.3]. The terms "Root AC" and "Leaf AC" are 


used in the following MEF service description. 
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For an E-LAN service, all ACs have the Root role, which means that 
any AC can communicate with other ACs in the service. The E-LAN 
service defined by the MEF may be implemented by IETF L2VPN solutions 
such as VPLS and EVPN [EVPN]. 


An E-Tree service has one or more Root ACs and at least two Leaf ACs. 
An E-Tree service supports communication among the roots and between 
a root and a leaf but prohibits communication among the leaves. 
Existing IETF L2VPN solutions can’t support the E-Tree service. This 
document specifies the E-Tree architecture reference model that 
supports the E-Tree service defined by the MEF [MEF6.1]. Section 4 
will discuss different E-Tree use cases. 


2:3. IETF L2VPN 
2.3.1. Virtual Private LAN Service (VPLS) 


VPLS [RFC4761] [RFC4762] is an L2VPN solution that provides 
multipoint-to-multipoint Ethernet connectivity across IP/MPLS 
networks.  VPLS emulates traditional Ethernet Virtual LAN (VLAN) 
services in MPLS networks and may support MEF E-LAN services. 


A data frame in VPLS is an Ethernet frame. Data forwarding in a VPLS 
instance is based on the destination MAC address and the VLAN on 
which the frame arrives. MAC reachability learning is performed in 
the data plane based on the source address and the AC or pseudowire 
(PW) on which the frame arrives. MAC aging is the mechanism used to 
remove inactive MAC addresses from a VPLS switching instance (VSI) on 
a PE. VPLS supports forwarding for known unicast frames, as well as 
unknown unicast, broadcast, and multicast Ethernet frames. 


Many service providers have deployed VPLS in their networks to 
provide L2VPN services to customers. 


2.3.2. Ethernet VPN (EVPN) 


Ethernet VPN [EVPN] is an enhanced L2VPN solution that emulates an 
Ethernet LAN or virtual LAN(s) across MPLS networks. 


EVPN supports active-active multihoming of CEs and uses the 
Multiprotocol Border Gateway Protocol (MP-BGP) control plane to 
advertise MAC address reachability from an ingress PE to egress PEs. 
Thus, a PE learns MAC addresses that are reachable over local ACs in 
the data plane and other MAC addresses reachable across the MPLS 
network over remote ACs via the EVPN MP-BGP control plane. As a 
result, EVPN aims to support large-scale L2VPN with better resiliency 
compared to VPLS. 
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EVPN is a relatively new technique and is still under development in 
the IETF L2VPN WG. 


2.3.3. Virtual Private Multicast Service (VPMS) 


VPMS [VPMS] is an L2VPN solution that provides point-to-multipoint 
connectivity across MPLS networks and supports various attachment 
circuit (AC) types, including Frame Relay, ATM, Ethernet, PPP, etc. 


In the case of Ethernet ACs, VPMS provides single coverage of 
receiver membership, i.e., there is no differentiation among 
multicast groups in one VPN. The destination address in the Ethernet 
frame is not used in data forwarding. 


VPMS supports unidirectional point-to-multipoint transport from a 
sender to multiple receivers and may support reverse transport in a 
point-to-point manner. 


3.  E-Tree Architecture Reference Model 
Figure 1 illustrates the E-Tree architecture reference model. Three 
Provider Edges -- PE1, PE2, and PE3 -- are shown in the figure. Each 


PE has a Virtual Service Instance (VSI) associated with an E-Tree 
service instance. A CE attaches to the VSI on a PE via an AC. Each 
AC must be configured with a Root or Leaf role. In Figure 1, AC], 
AC2, AC5, AC6, AC9, and AC10 are Root ACs; AC3, AC4, AC7, AC8, AC11, 
and AC12 are Leaf ACs. This implies that a PE (local or remote) 
processes the Ethernet frames from CEO1, CE02, etc., as if they 
originated from a Root AC, and it processes the Ethernet frames from 
CE03, CE04, etc., as if they originated from a Leaf AC. 


Under this architecture model, the forwarding rules among the ACs, 
regardless of whether the sending AC and receiving AC are on the same 
PE or on different PEs, are described as follows: 


o An egress frame (the frame to be transmitted over an AC) at an AC 
with Root role must be the result of an ingress frame at an AC 
(the frame received at an AC) that has Root or Leaf role and is 
attached to the same E-Tree service instance. 


o An egress frame at the AC with Leaf role must be the result of an 
ingress frame at an AC that has Root role and is attached to the 
same E-Tree service instance. 
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uenis E-Tree--5---5-——-—-—-— > 
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Figure 1: E-Tree Architecture Reference Model 


These rules apply to all frame types, i.e., known unicast, unknown 
unicast, broadcast, and multicast. For known unicast frames, 
forwarding in a VSI context is based on the destination MAC address. 


A VSI on a PE corresponds to an E-Tree service instance and maintains 
a MAC forwarding table that is isolated from other VSI tables on the 
PE. It also keeps track of local AC roles. The VSI receives a frame 
from an AC or across the MPLS core, and it forwards the frame to 
another AC over which the destination is reachable according to the 
VSI forwarding table and forwarding rules described above. When the 
target AC is on a remote PE, the VSI forwards the frame to the remote 
PE over the MPLS core. Forwarding over the MPLS core will be 
dependent on the E-Tree solution. For instance, a solution may adopt 
PWs to mesh VSIs as in VPLS and to forward frames over VSIs subject 
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to the E-Tree forwarding rules. Alternatively, a solution may adopt 
the EVPN forwarding paradigm constrained by the E-Tree forwarding 
rules. Thus, solutions that satisfy the E-Tree requirements could be 
extensions to VPLS and EVPN. 


In most use cases, an E-Tree service has only a few Root ACs (root CE 
sites) but many Leaf ACs (leaf CE sites). Furthermore, a PE may have 
only Root ACs or only Leaf ACs. Figure 1 provides a general E-Tree 
architecture model. 


4. E-Tree Use Cases 


Table 1 below presents some major use cases for E-Tree. 


R-—-------------------------- 4R-------------- R-—---------- * 
| Use Case | Root AC | Leaf AC | 
R-—-—4--------------------------- 4R-—------------ 4R-—---------- * 
| 1 | Hub & Spoke VPN | Hub Site | Spoke Site | 
4-—-—4--------------------------- R-------------- R-—---------- * 
| 2 | Wholesale Access | Customer's | Customer's | 
| | | Interconnect | Subscriber | 
4---4+--------------------------- 4-------------- R-—---------- * 
| 3 | Mobile Backhaul | RAN NC | RAN BS 
4-—-—4--------------------------- 4R-------------- R-—---------- * 
| 4 | IEEE 1588 PTPv2 [IEEE1588]| PTP Server | PTP Client | 
| | Clock Synchronization | | | 
+---+--------------------------- aA AA R + 
5 Internet Access BNG Router Subscriber 
Reference [TR-101] 
4-—-4+--------------------------- e +------------ + 
| 6 | Broadcast Video | Video Source | Subscriber | 
| | (unidirectional only) | | 
e E AR 4-------------- R-—---------- * 
7 Broadcast/Multicast Video Video Source Subscriber 
plus Control Channel 
4-—-—4--------------------------- 4R-------------- R-—---------- * 
| 8 | Device Management | Management | Managed 
| | | System | Device | 
4-—-4+--------------------------- R-—------------ R-—---------- * 
Where: 
RAN: Radio Access Network NC: Network Controller 
BS: Base Station PTP: Precision Time Protocol 


BNG: Broadband Network Gateway 


Table 1: E-Tree Use Cases 
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Common to all use cases, direct Layer 2 leaf-to-leaf communication is 
required to be prohibited. For mobile backhaul, this may not be 
valid for Long Term Evolution (LTE) X2 interfaces; an LTE X2 
interface [LTE] enables communication between two evolved Node Bs 
(eNBs). E-Tree service is appropriate for such use cases. 


Also common to the use cases mentioned above, there may be one or 
multiple Root ACs in one E-Tree service. The need for multiple Root 
ACs may be driven by a redundancy requirement or by having multiple 
serving sites. Whether a particular E-Tree service needs to support 
one or multiple Root ACs depends on the application. 


5. L2VPN Gaps for Emulating MEF E-Tree Service 


The MEF E-Tree service defines special forwarding rules that prohibit 
forwarding Ethernet frames among leaves. This poses some challenges 
to IETF L2VPN solutions such as VPLS and EVPN in emulating E-Tree 
service over an MPLS network. There are two major issues described 
in the following subsections. 


5.1. No Differentiation on AC Role 


IP/MPLS L2VPN architecture has no distinct roles on Attachment 
Circuits (ACs) and supports any-to-any connectivity among all ACs. 
It does not have any mechanism to support forwarding constraints 
based on an AC role. However, the MEF E-Tree service defines two AC 
roles -- Root and Leaf -- and defines the forwarding rules based on 
the originating and receiving AC roles of a given frame. 


5.2. No AC Role Indication or Advertisement 


In an L2VPN, when a PE, say PE2, receives a frame from another PE, 
say PE1, over the MPLS core, PE2 does not know if the frame from PE1 
is originated from a Root AC or Leaf AC. This causes the forwarding 
issue on PE2 because the E-Tree forwarding rules require that the 
forwarder must know the role of the frame origin, i.e., from Root AC 
or Leaf AC. This is specifically important when PE2 has both Root AC 
and Leaf AC attached to the VSI. E-Tree forwarding rules apply to 
all types of frames (known unicast destination, unknown unicast 
destination, multicast, and broadcast). 


5.3. Other Issues 


Some desirable requirements for IETF E-Tree are specific to an 
IP/MPLS L2VPN implementation such as Leaf-only PE. A Leaf-only PE is 
a PE that only has Leaf AC(s) in an E-Tree service instance; thus, 
other PEs on the same E-Tree service instance do not necessarily 
forward the frames originated from a Leaf AC to the Leaf-only PE, 
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which may save some network resources. It is also desirable for an 
E-Tree solution to work with existing PEs that support single-role 

ACs, where the role is equivalent to the root in an E-Tree service. 
These requirements are described in the E-Tree requirement document 
[RFC7152]. 


6. Security Considerations 


An E-Tree service may be deployed for security reasons to prohibit 
communication among sites (leaves). An E-Tree solution must enforce 
E-Tree forwarding constraints. The solution must also guarantee that 
Ethernet frames do not leak outside of the E-Tree service instance to 
which they belong. 


An E-Tree service prohibits communication among leaf sites but does 
not have knowledge of higher-layer security constraints. Therefore, 
in general, higher-layer applications cannot rely on E-Tree to 
provide security protection unless all security constraints are fully 
implemented by the E-Tree service. 


Enhancing L2VPN for E-Tree services inherits the same security issues 
described in the L2VPN framework document [RFC4664]. These relate to 
both control-plane and data-plane security issues that may arise in 
the following areas: 


o issues fully contained in the provider network 
o issues fully contained in the customer network 
o issues in the customer-provider interface network 


The framework document has substantial discussions on the security 
issues and potential solutions to address them. An E-Tree solution 
must consider these issues and address them properly. VPLS [RFC4761] 
[RFC4762] and/or EVPN [EVPN] will likely be candidate solutions for 
an E-Tree service over an MPLS network. The security capabilities 
built into those solutions will be naturally adopted when supporting 
E-Tree. For details, see the Security Considerations sections in 
[RFC4761], [RFC4762], and [EVPN]. 
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